Content such as music, movies, and the like can be provided over cable or satellite for recording and playback by viewers. To protect the rights of content providers, the content may be encrypted. Only authorized viewer devices are given the decryption information (e.g., decryption keys) that is necessary to unlock and play the content.
As an example, an audio-video frame of data (with thirty or so frames making up one second of an audio-video program) might be sent to a viewer device in packets that make up a so-called “transport stream” (TS). Each packet can be, for instance, 188 bytes long, with each packet potentially being encrypted separately from the other packets.
In one current implementation, each packet can include a header portion. In the header portion, an encryption-indicating bit group referred to as a “transport scrambling control” (TSC) group can be included to indicate whether the particular packet is encrypted and if so, whether the “polarity” of the encryption key to be used is even or odd. Essentially, keys can be provided in pairs, with one key being designated “odd” and the other key “even”. The keys themselves may be provided in the header of an encrypted packet in an “entitlement control message” (ECM). Also included in the header can be bits that indicate whether the packet contains the start of a frame. In one current non-limiting implementation these bits can be referred to as “payload_unit_start_indicator” (PUSI) bits and/or “random_access_indicator” (RAI) bits.
The keys ordinarily are encrypted. To unlock the content, the key for a sequence of packets must first be decrypted and then used to unlock the actual A/V data in the packet which is associated with the key. To facilitate timely decryption, the key that corresponds to a sequence of packets can be provided in an ECM packet that precedes the sequence of packets, so that a key may be authorized, decrypted and ready for use when the packets to which it applies are to be unlocked.
While the above-described content encryption method is effective, the present invention makes the following critical observations. It is sometimes the case that content is downloaded and recorded for later playback by a viewer. It is further the case that the content may be speculatively downloaded, i.e., sent in an encrypted form to a viewer's device for later decryption and playback once the viewer has paid for the content and has received the necessary key decryption information. Still further, the present invention recognizes that it is desirable to provide “trick mode” playback, i.e., to allow a viewer to fast forward through the content, pause, reverse, etc., i.e., to play the transport stream at a rate or in a direction or even in a packet sequence other than envisioned for normal playback mode. The present invention understands that such trick mode playback, particularly in the case of speculatively recorded content, poses complications in coordinating the decryption process discussed above, particularly in knowing what keys are required for the frame being jumped to and in having the keys ready on time to decrypt the content just prior to its being played.